RBIProxy 사설 CA 요구사항
문서 목적
RBIProxy의 HTTPS 중계(MITM) 서명에 사용될 사설 CA의 기술 요구사항을 정의합니다.
본 문서는 고객사 PKI 담당자가 CA를 발급·전달할 때 참조합니다.
| 항목 | 내용 |
|---|---|
| 적용 제품 | RBIProxy (Kubernetes 배포) |
| 후속 문서 | 02. RBIProxy 사설 CA 적용 엔지니어 가이드 |
📌 요약 — 반드시 확인해 주십시오
- 키 알고리즘: 현재 릴리즈는 RSA 2048bit 이상이 필수입니다. ECDSA 등 타 알고리즘은 동작이 보장되지 않으므로 RSA를 사용해 주십시오.
- 키 포맷: PKCS#8 PEM 평문 필수 (
-----BEGIN PRIVATE KEY-----).- 권장 방식: 가장 단순한 "전용 Self-Signed Root CA 1장" 방식이 권장됩니다. Intermediate CA 방식도 가능하나 4.5절의 체인 전송 제약을 반드시 확인해 주십시오.
- 본 CA의 용도 한정: RBIProxy의 HTTPS 중계 서명 전용으로 발급하시고, 기존 PKI 업무용 CA(코드 서명, 이메일 등)와 분리 운영이 필요합니다.
1. 개요
1.1 배경
RBIProxy는 사용자의 HTTPS 트래픽을 중계(MITM) 하여 Remote Browser Isolation(RBI) 서비스로 전달합니다.
이 과정에서 RBIProxy는 목적지 도메인(예: www.example.com)의 서버 인증서를 동적으로 재발급하여 사용자 브라우저에 제공하는데, 재발급 시 서명자(Issuer)로 사용할 CA 인증서/개인키 1쌍이 필요합니다.
기본 제공 CA(제품에 포함)를 사용하지 않고 고객사 자체 PKI를 활용하고자 하는 경우, 본 문서의 요구사항을 충족하는 CA를 준비해 주셔야 합니다.
1.2 자체 CA 적용이 검토되는 경우
다음 중 하나라도 해당하시면 자체 CA 적용이 필요합니다.
- 기본 제공 CA 사용에 따른 브라우저 경고를 제거하고 싶은 경우
- 고객사별 인증서 분리 운영이 내부 보안 정책상 필요한 경우
- 기존 사내 PKI 체계와 통합 관리가 필요한 경우
- 금융권·공공 등 감사 대응상 고유 CA 사용이 필요한 경우
💡 PoC나 단순 테스트 단계에서는 별도 작업 없이 기본 제공 CA를 그대로 사용하실 수 있습니다.
1.3 동작 구조 (요약)
- 사용자 PC가 외부 사이트(예:
https://www.example.com)로 HTTPS 접속을 요청합니다. - RBIProxy가 요청을 받아, 사설 CA로 해당 도메인의 서버 인증서를 즉석 발급하여 사용자 브라우저에 전달합니다.
- 사용자 브라우저는 사설 Root CA를 신뢰하고 있으므로 체인 검증이 통과되어 경고 없이 정상 처리됩니다.
- RBIProxy는 실제 외부 사이트로 트래픽을 중계합니다.
※ 이 흐름이 동작하려면 사용자 PC에 사설 Root CA가 신뢰할 수 있는 루트 인증 기관으로 사전 등록되어 있어야 합니다 (AD GPO 등 통한 배포).
1.4 전체 진행 절차
| 단계 | 주체 |
|---|---|
| 1. 본 문서 검토 및 CA 발급 방식 결정 | PKI 담당자 |
| 2. CA 인증서/개인키 발급 | PKI 담당자 |
| 3. 사용자 PC Root CA 배포 (GPO 등) | IT 담당자 |
| 4. 보안 채널을 통한 파일 전달 | PKI 담당자 → 구축 담당자 |
| 5. RBIProxy에 반영 | 구축 담당자 |
| 6. 동작 검증 | 양측 합동 |
ℹ️ "구축 담당자"는 RBIProxy를 운영 중인 Kubernetes 환경에 직접 작업하는 담당자를 의미합니다. 구축 형태에 따라 사내 IT 인프라 담당자, 위탁 SI 엔지니어, 또는 제품 공급사 엔지니어 중 한쪽이 될 수 있습니다. 본 문서 전반에서 동일한 의미로 사용됩니다.
2. 전제 조건
2.1 갖추어져 있어야 하는 환경
| 구분 | 요구사항 |
|---|---|
| 사설 Root CA | 사내 자체 Root CA (또는 내부 PKI)가 이미 운영 중 |
| 사용자 PC 배포 체계 | 모든 대상 PC에 사설 Root CA가 "신뢰할 수 있는 루트 인증 기관"으로 배포되어 있음 (AD GPO 등) |
| 배포 방식 | Windows 시스템 인증서 저장소 기반 (Edge/Chrome/IE 참조) |
2.2 효과 범위
| 브라우저/클라이언트 | 지원 | 비고 |
|---|---|---|
| Microsoft Edge | ✅ | Windows 시스템 인증서 저장소 사용 |
| Google Chrome | ✅ | Windows 시스템 인증서 저장소 사용 |
| Internet Explorer | ✅ | Windows 시스템 인증서 저장소 사용 |
| Firefox | ⚠️ 별도 설정 | GPO로 security.enterprise_roots.enabled = true 또는 자체 TrustStore에 등록 |
| Java/.NET 등 응용 프로그램 | ⚠️ 별도 대응 | 각 런타임의 TrustStore에 별도 등록 필요 |
| macOS / Linux 단말 | ⚠️ 별도 대응 | 각 OS 인증서 저장소에 Root CA 등록 필요 |
3. 전달해야 할 파일 (납품물)
다음 파일들을 보안 전달 채널로 구축 담당자에게 전달해 주십시오.
| # | 파일 | 필수/선택 | 포맷 | 설명 |
|---|---|---|---|---|
| 1 | CA 인증서 (Self-Signed Root 또는 Intermediate) | 필수 | PEM (.crt / .pem) | RBIProxy가 서명용으로 사용할 CA |
| 2 | CA 개인키 | 필수 | PKCS#8 PEM 평문 (.key / .pem) | 위 인증서의 대응 Private Key |
| 3 | Intermediate 체인 (중간 CA들) | 조건부 (Intermediate 방식) | PEM 번들 | Root와 발급 CA 사이에 다른 중간 CA가 있는 경우 모두 포함 (Root 제외) |
| 4 | Root CA 공개 인증서 | 필수 | PEM | 검증용. Self-Signed Root 방식이라면 #1과 동일 파일도 무방 |
3.1 전달 형식 예시
옵션 A: 분리 파일 (권장)
customer-ca.crt ← #1 (단일 또는 #1+#3 체인 번들)
customer-ca.key ← #2 (PKCS#8 평문)
customer-root-ca.crt ← #4 (검증용)
옵션 B: 통합 PEM
customer-ca-bundle.pem ← #1 + #2 + #3 모두 포함
customer-root-ca.crt ← #4 (검증용)
옵션 C: PKCS#12 (.pfx)
customer-ca.pfx ← #1 + #2 + #3 통합 (암호화됨)
* 패스워드는 별도 채널로 전달
customer-root-ca.crt ← #4 (검증용)
ℹ️ RBIProxy 런타임은 PEM 포맷을 직접 로드합니다. PKCS#12로 전달받은 경우 구축 담당자가 OpenSSL로 PEM(cert + key)으로 변환하여 반영합니다. 변환 과정에서 개인키를 평문 상태로 일시 보관하게 되므로, 보안상 옵션 A(분리 파일) 가 필요합니다.
3.2 보안 전달 채널 (권장)
개인키가 포함된 파일은 반드시 아래 중 하나 이상의 방식으로 전달해 주십시오.
| 방식 | 권장 수준 | 비고 |
|---|---|---|
| PKCS#12 + 패스워드 별도 채널 분리 전달 | ⭐⭐⭐ | 파일은 메일, 패스워드는 유선/SMS |
| 사내 파일 암호화 솔루션 | ⭐⭐⭐ | 보유 중인 경우 |
| 암호화 USB + 대면 전달 | ⭐⭐ | 오프라인 전달 가능 시 |
| S/MIME 암호화 메일 | ⭐⭐ | 상호 인증서 교환 필요 |
| 일반 메일 첨부 (평문) | ❌ | 금지 |
📌 전달 완료 후 고객사 측에서 전달용 평문 파일을 즉시 파기해 주십시오.
3.3 키 포맷 주의사항
Private Key는 다음 조건을 모두 충족해야 합니다.
| 항목 | 필수 사항 |
|---|---|
| 래핑 포맷 | PKCS#8 PEM (-----BEGIN PRIVATE KEY-----) |
| 키 알고리즘 | RSA 2048bit 이상 (RSA 3072/4096 가능) |
| 암호화 여부 | 평문 (전달 채널에서 보호) |
PKCS#8 예시 (권장)
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASC...
-----END PRIVATE KEY-----
PKCS#1 (-----BEGIN RSA PRIVATE KEY-----) 을 보유 중인 경우 — 변환 필수
openssl pkcs8 -topk8 -nocrypt \
-in customer-ca-pkcs1.key \
-out customer-ca-pkcs8.key
암호화된 PEM(-----BEGIN ENCRYPTED PRIVATE KEY-----) 을 보유 중인 경우 — 복호화 필수
openssl pkcs8 -in customer-ca-encrypted.key -out customer-ca-plain.key
# 패스워드 입력 후 평문 PKCS#8로 저장됨
⚠️ 변환/복호화된 평문 개인키 파일은 보안 전달 채널(3.2절 참조)로 전달하시고, 전달 완료 후 원본 파일을 즉시 파기해 주십시오.
4. CA 인증서 필수 요건 (X.509 확장)
CA 인증서는 다음 요건을 모두 충족해야 합니다. 기존에 다른 용도(코드 서명, 이메일 보호 등)로 발급된 CA를 재활용하는 것은 권장되지 않으며, "TLS 서버 인증서 발급용 CA" 로 신규 발급하셔야 합니다. (Self-Signed Root / Intermediate 모두 동일 요건)
4.1 X.509 확장 필드 필수 요건
| 확장 필드 | 필수 값 | 비고 |
|---|---|---|
| Basic Constraints | CA:TRUE | 필수 — CA 인증서임을 명시 |
| Key Usage | keyCertSign, cRLSign | 필수 — 일부 브라우저는 미설정 시 경고 발생 |
| Extended Key Usage (EKU) | serverAuth 포함 | 필수 — TLS 서버 인증서 발급 용도 명시 |
| Name Constraints | 미설정 필요 | 설정 시 해당 도메인만 중계 가능 |
| Path Length Constraint | pathlen >= 0 | end-entity 발급 가능 |
ℹ️ Key Usage / Extended Key Usage는 최신 브라우저(특히 Chrome 계열)에서 점차 엄격하게 검증하는 추세입니다. 명시적으로 설정하시면 호환성 측면에서 안전합니다.
4.2 키/알고리즘 필수 요건
| 항목 | 필수 사항 |
|---|---|
| 키 타입 | RSA 2048bit 이상 (3072 / 4096 가능) |
| 서명 알고리즘 | SHA-256 이상 (SHA-1 사용 불가) |
| 유효기간 | 3년 이상 필요 |
ℹ️ ECDSA 등 타 알고리즘은 현재 릴리즈에서 동작이 보장되지 않으므로 RSA 사용이 필수입니다.
4.3 OpenSSL 셀프 체크 (전달 전)
전달 전에 아래 명령으로 요건 충족 여부를 확인하실 수 있습니다.
openssl x509 -in customer-ca.crt -noout -text
출력에서 다음 항목 확인:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
TLS Web Server Authentication
4.4 체인 검증
openssl verify -CAfile customer-root-ca.crt customer-ca.crt
# 출력: customer-ca.crt: OK
4.5 Intermediate CA 운영 시 체인 전송 제약
⚠️ 본 섹션은 Intermediate CA 방식으로 운영할 때 반드시 알아야 할 제약입니다. Self-Signed Root CA 1장 방식을 선택한 경우 해당 없음.
현상
현재 RBIProxy는 사용자 브라우저에게 동적 발급한 leaf 인증서를 전송하지만, 그 위 단계의 Intermediate CA를 함께 전송하지 않을 수 있습니다.
영향
사용자 PC에 Root CA만 설치되어 있다면, 브라우저는 leaf → (빠진 Intermediate) → Root 체인을 완성하지 못해 NET::ERR_CERT_AUTHORITY_INVALID 등의 경고를 표시할 수 있습니다.
해결 방법 — 아래 A 또는 B 중 택일
A. (권장) 전용 Self-Signed Root CA 사용
- 체인 길이가 1(Root → leaf)이므로 중간 단계 자체가 없음 → 본 제약 해당 없음
- 기존 PKI와 분리된 "RBIProxy 전용 Root CA 1장" 을 신규 발급하여 전달
- 사용자 PC에는 해당 Root CA만 Trusted Root에 배포
B. Intermediate CA 방식을 고수하는 경우
- 사용자 PC에 Intermediate CA까지 반드시 배포
- Windows: "중간 인증 기관(Intermediate Certification Authorities)" 저장소에 Intermediate CA 배포
- GPO 배포 시 Root CA 배포와 동일 정책에 함께 포함 필요
- 2단 이상의 Intermediate 체인이라면 중간 단계 모두 배포
판정 매트릭스
| 전달받은 CA 종류 | 사용자 PC에 배포할 인증서 | 브라우저 동작 |
|---|---|---|
| 전용 Self-Signed Root CA | Root CA만 | ✅ 정상 |
| Intermediate CA (1단) | Root CA + Intermediate CA | ✅ 정상 |
| Intermediate CA (1단) | Root CA만 | ❌ 경고 발생 가능 |
| Intermediate CA (2단 이상) | Root CA + 모든 중간 CA | ✅ 정상 |
4.6 키 포맷 확인
head -1 customer-ca.key
# "-----BEGIN PRIVATE KEY-----" ← PKCS#8 (필수)
# "-----BEGIN RSA PRIVATE KEY-----" ← PKCS#1 (변환 필수)
# "-----BEGIN ENCRYPTED PRIVATE KEY-----" ← 암호화됨 (복호화 필수)
키 알고리즘 확인
openssl pkey -in customer-ca.key -noout -text | head -2
# "RSA Private-Key: (2048 bit, 2 primes)" ← 필수
# "ED25519 Private-Key:" 또는 EC 표시 → RSA로 재발급 필요
5. 사용자 PC 환경 요구사항
5.1 Root CA 배포 상태 확인 (Windows)
# PowerShell (관리자 권한)
Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Subject -like "*<사내 CA명>*" }
또는 GUI: certlm.msc → 신뢰할 수 있는 루트 인증 기관 > 인증서 에서 사설 Root CA 존재 확인.
5.2 Firefox 사용 시 추가 설정 (선택)
Firefox는 기본적으로 자체 TrustStore를 사용합니다. Windows 시스템 저장소를 신뢰하도록 하려면 GPO 또는 policies.json로 다음 설정 배포:
{
"policies": {
"Certificates": {
"ImportEnterpriseRoots": true
}
}
}
또는 about:config → security.enterprise_roots.enabled = true
5.3 macOS / Linux 단말 지원
| OS | Root CA 배포 방법 |
|---|---|
| macOS | Keychain Access → 시스템 키체인에 Root CA 추가 → 신뢰 설정 "항상 신뢰" |
| Ubuntu/Debian | /usr/local/share/ca-certificates/ 에 복사 후 sudo update-ca-certificates |
| RHEL/CentOS | /etc/pki/ca-trust/source/anchors/ 에 복사 후 sudo update-ca-trust |
6. 보안/운영 고려사항
6.1 개인키 보호
- 전달된 CA 개인키는 Kubernetes Secret 으로 저장되며, RBIProxy Pod에 read-only 볼륨으로 마운트됩니다.
- Secret 접근 권한은 해당 네임스페이스 관리자로 최소화됩니다.
- 필요시 KMS/HSM 연동을 별도 검토할 수 있습니다.
6.2 감사 로그
현재 동작
- RBIProxy는 동적 발급한 leaf 인증서의 건별 발급 이력을 별도 로그로 남기지 않습니다 (성능 고려).
- 다만 다음 범주의 로그는 기록됩니다.
- 접근 로그: 사용자가 접속한 외부 도메인 (CONNECT 로그)
- CA 로드 이벤트: Pod 기동 시 CA 개인키 로드 성공/실패
- Secret 변경: Kubernetes Audit Log (클러스터 수준)
엄격한 감사 요건이 있는 경우
발급된 leaf 인증서의 시리얼 번호, 발급 시각, 대상 도메인 등을 전량 기록해야 하는 등 별도 감사 요구사항이 있는 경우, 구축 담당자를 통해 별도 협의를 요청해 주십시오.
6.3 인증서 교체 (롤오버)
- CA 만료 최소 90일 전 신규 발급 및 전달이 필요합니다.
- 교체는 Kubernetes Secret 재생성 + Pod 재기동만으로 반영 가능합니다 (짧은 세션 끊김 수반).
6.4 폐기 (Revocation)
- RBIProxy가 동적으로 발급하는 leaf 인증서에는 CRL/OCSP URL이 포함되지 않습니다 (임시 발급 특성).
- CA 자체의 폐기 이력은 사내 CRL/OCSP 체계에 기록됩니다.
6.5 운영 중 CA 변경 시
- CA 교체는 짧은 세션 끊김(Pod 재기동, 통상 1분 이내)을 수반합니다.
- 대규모 사용자 영향 을 최소화하기 위해 업무 외 시간대 변경이 필요합니다.
- 변경 전후 최소 30일 동안은 이전 CA를 폐기하지 마시고 보관해 주십시오 (롤백 대비).
7. 체크리스트 (PKI 담당자 확인용)
전달 전에 아래 항목을 확인해 주십시오.
공통 (모든 방식)
-
CA 방식 결정: Self-Signed Root CA 전용 또는 Intermediate CA
-
"TLS 서버 인증서 발급용" CA를 신규 발급
-
Basic Constraints: CA:TRUE -
Key Usage: keyCertSign, cRLSign(필수) -
Extended Key Usage: serverAuth포함 (필수) -
Name Constraints 미설정 (또는 RBI 중계 대상 도메인 모두 포함)
-
키 알고리즘 = RSA 2048bit 이상
-
SHA-256 이상 서명
-
유효기간 3년 이상
개인키 포맷
-
개인키가 PKCS#8 PEM 포맷 (
-----BEGIN PRIVATE KEY-----) -
개인키가 평문 (암호화되지 않음)
사용자 PC 배포
-
Self-Signed Root CA 방식: 해당 Root CA가 모든 대상 사용자 PC의 "신뢰할 수 있는 루트 인증 기관" 에 배포 완료
-
Intermediate CA 방식: Root CA가 "신뢰할 수 있는 루트 인증 기관" 에, Intermediate CA가 "중간 인증 기관" 에 함께 배포 완료 (4.5절 참조)
전달 준비
-
openssl verify -CAfile <Root> <Intermediate>검증 OK (Intermediate 방식) -
Root CA 공개 인증서(검증용) 함께 전달
-
보안 전달 채널(3.2절 참조) 준비 완료
-
전달용 평문 파일의 파기 시점 사전 결정
8. FAQ
Q1. Root CA의 개인키를 전달해야 하나요?
A. 아닙니다. Root CA 개인키는 사내 최고 보안 자산이므로 전달하지 마십시오. 전용 Self-Signed Root CA를 신규 발급하거나, 기존 Root CA 하위에 Intermediate CA를 신규 발급하여 전달하십시오.
Q2. 기존 내부 웹서버용 인증서를 그대로 사용할 수 있나요?
A. 불가합니다. 일반 서버 인증서(end-entity)는 CA:FALSE로 발급되어 하위 인증서 서명 권한이 없습니다. CA 인증서를 신규 발급해야 합니다.
Q3. Self-Signed CA와 Intermediate CA 중 어느 쪽을 선택해야 하나요?
A. 전용 Self-Signed Root CA 1장을 권장합니다. Intermediate CA 방식은 사용자 PC에 Intermediate까지 별도 배포하는 번거로움이 있습니다(4.5절 참조). 기존 내부 PKI 통합 감사 등 특별한 요구가 없다면 Self-Signed 방식이 단순하고 확실합니다.
Q4. ECDSA 키로 발급해도 되나요?
A. 현재 릴리즈에서는 동작이 보장되지 않으므로 RSA 2048bit 이상으로 발급해 주십시오.
Q5. 유효기간이 짧은 CA(1년 등)도 가능한가요?
A. 기술적으로 가능하나, 매년 재전달/재배포 부담이 발생합니다. 3년 이상이 필요합니다.
Q6. Name Constraints로 제한된 CA를 줘도 되나요?
A. 가능하나, 해당 Name Constraint에 포함되지 않은 도메인은 RBIProxy를 통해 접속할 때 브라우저 경고가 발생합니다. RBI 중계 대상 도메인 범위를 정확히 합의한 후 설정해 주십시오.
Q7. 개인키 포맷이 PKCS#1 (-----BEGIN RSA PRIVATE KEY-----)인데 그대로 보내도 되나요?
A. 사용 불가합니다. openssl pkcs8 -topk8 -nocrypt 명령으로 변환 후 전달이 필요합니다(3.3절 참조).
Q8. PKCS#12(.pfx) 파일만 있습니다. 이대로 보내도 되나요?
A. 전달 가능합니다. 다만 RBIProxy 런타임이 PEM을 사용하므로, 구축 담당자가 내부에서 PEM으로 변환하여 반영합니다. 보안 관점에서 처음부터 분리된 PEM 파일(옵션 A) 로 전달이 필요합니다.
Q9. 인증서가 만료되면 서비스가 어떻게 되나요?
A. 만료된 CA를 그대로 두면 새 세션 생성 시 브라우저 경고가 발생하여 RBI 서비스를 정상 이용하지 못할 수 있습니다. 만료 90일 전부터 갱신을 준비해 주십시오.
Q10. 여러 환경(운영/스테이징)에 각각 다른 CA를 쓸 수 있나요?
A. 가능합니다. Kubernetes Secret을 환경별로 분리 생성하여 각 환경 Deployment에 별도 마운트하면 됩니다. 운영/스테이징의 CA를 분리하면 스테이징 CA 유출 시에도 운영에 영향이 없으므로 분리가 필요합니다.